About SequeLink^® Security

SequeLink supports security mechanisms for the following purposes:

Verification of a user by the SequeLink Server. The Authentication security mechanism allows the SequeLink Server to verify the identity of the user.
Defining the types of requests that are accepted by the server. The Authorization security mechanism controls whether the user can send data access requests and administrative (SequeLink Manager) requests. Server configuration settings determine whether the server can accept the requests.
Connection to a data store using the following security mechanisms:
Data Store Logon controls whether a user who is connected to the SequeLink Server can connect to the data store.
Application IDs control whether a client application can connect to the data store. This mechanism adds a layer of security on top of Data Store Logon.
TCP/IP Location Filters control whether a client application can connect to the data store based on the TCP/IP network identifier from which the connection request orginates.
Terminal Security is supported for connections to SequeLink Servers on z/OS. It controls whether the client application requesting access to the SequeLink data access service has permission to access it based on the TCP/IP address (terminal ID) originating the request.
Defining the types of SQL statements accepted by the data store. The ReadOnly security mechanism controls whether the data store connection is read-only.
The privacy of the data being transmitted. The data privacy security mechanism ensures that data transmitted between the client and server is kept private using data scrambling methods and encryption using SSL. SSL is supported for the ODBC Client, JDBC Client, and ADO Client.

Authentication

Authentication allows the SequeLink Server to verify the identity of the SequeLink Client when the client connects to the SequeLink Server. If authentication fails, the SequeLink Client disconnects from the server.

You must set an authentication method separately for users who send data access requests and users who send SequeLink Manager requests. For example, you may want to use an operating system user ID and password for administrative activities and Kerberos for data access activities.

Depending on the combination of client and server platforms involved in the connection, SequeLink supports the following authentication methods:

Anonymous. The SequeLink Server accepts connections from any SequeLink Client without verifying the client's identity.
Operating system user ID and password. The SequeLink Server verifies the identity of the SequeLink Client using a user ID and password that must be valid for the platform on which the SequeLink Server is running. If verified, the server accepts the user ID as the identity of the client and permits the connection.
Kerberos. Kerberos authentication uses Kerberos, a trusted third-party authentication service, to verify user identities. Kerberos authentication can take advantage of the user name and password maintained by the operating system to authenticate users to the database. This method requires knowledge of how to configure your Kerberos environment.


Integrated NT. This option is supported for connections between SequeLink Server for Windows servers and ODBC Clients, ADO Clients, and .NET Clients on Windows only. The SequeLink Server verifies the identity of the SequeLink Client using the client's Windows network logon credentials instead of a Windows user ID and password.

Although a user may be able to connect to the SequeLink Server, the user does not automatically have access to the database that the SequeLink Server services.

For instructions on configuring authentication:

On Linux, UNIX, and Windows, see "Configuring SequeLink® Security on Linux, UNIX, and Windows".
On z/OS, see "Configuring SequeLink® Security for z/OS".

Authorization

After the SequeLink Server has authenticated the client, SequeLink verifies that the client is authorized to perform data access activities or SequeLink Manager activities. SequeLink supports authorization for data access requests and for SequeLink Manager requests. You configure the authorization for the two types of requests separately. Authorization options depend on your SequeLink Server platform.

For instructions on configuring authorization:

On Linux, UNIX, and Windows, see "Configuring SequeLink® Security on Linux, UNIX, and Windows".
On z/OS, see "Configuring SequeLink® Security for z/OS".

Data Store Logon

Once a connection is established, authentication is complete, and the type of requests the server will accept has been established, a connection from the SequeLink Server to the data store can be established using either of the following methods:

Specifying data store logon information (a valid DBMS user ID and password). This is the default for Windows and UNIX.
Allowing the database to inherit the logon user ID that was established during the authentication process. For example, if using Kerberos authentication, use this method to allow Kerberos to use the operating system user ID and password.This method must be used for z/OS, but can be used for Linux, UNIX, and Windows also.

For details on configuring data store logon, see "Configuring SequeLink® Security on Linux, UNIX, and Windows".

Application IDs

Application IDs are alphanumeric strings passed by a SequeLink Client that identify the client application to a SequeLink service that has been configured to accept connections only from specific application IDs.

Application IDs add another layer of security for the connection to the data store beyond that provided by the Data Store Logon security mechanism. Data Store Logon allows all users of client applications to access the data store if they meet the qualifications set by Data Store Logon. Using application IDs, you can restrict connections to the data store to only those client applications that identify themselves to the SequeLink Server through an application ID.

On Windows platforms, application IDs can be specified explicitly by the client application or they can be automatically generated by the ODBC Client or the ADO Client. The advantage of using application IDs generated by the ODBC Client or ADO Client is the application itself does not need to contain the application ID; however, you must specify in the client application that you want to turn on the automatic generation of application IDs. The application ID is generated using the sha-1 hashing algorithm, resulting in a 160-bit hash value.

See "Using Application IDs to Restrict User Access" for more information.

TCP/IP Location Filters

Using TCP/IP network identifiers, such as TCP/IP host names (for example, burner.ddtek.com) or a range of TCP/IP addresses (for example, 192.16.*.*), TCP/IP location filters allow you to specify which clients can access a SequeLink data access service or SequeLink agent service.

When you create a filter, the IP address can contain wild card characters to indicate that any decimal number in that location is considered valid. Use ? for a single number or * for multiple numbers. Use \ as the escape character.

The following address and name formats are supported:

Client TCP/IP host name	burner.ddtek.com
Client TCP/IP domain names through the use of a wild card	192.16.2.* *.ddtek.com belg?.progress.com
Client TCP/IP address	127.0.45.1??
Client TCP/IP address range	192.16.*.*

For more information about configuring TCP/IP location filters, see "Configuring TCP/IP Location Filters".

Terminal Security

When terminal security is enabled, through activating the RACF TERMINAL security class, the SequeLink Server verifies that the client application requesting access to the SequeLink data access service has permission to access it based on the TCP/IP address (terminal ID) originating the request. You can use terminal security to make sure that:

Only specific TCP/IP addresses can be used by specific users to connect to the SequeLink Server.
Only specific groups of users can use specific TCP/IP addresses to connect to the SequeLink Server. For example, you may want to make sure that a user ID associated with an application running on an application server can only log on to the SequeLink Server from a specific TCP/IP address.

See "Activating Terminal Security" for more information about activating terminal security.

Terminal security is controlled by activating the RACF TERMINAL security class instead of setting a service attribute.

ReadOnly

SequeLink allows you to configure the types of SQL statements the data store connection will accept:

Select statements only (makes the connection read-only)
Select statements and Stored Procedures
All SQL statements
Read-only settings of the database

The service attribute that controls this functionality is DataSourceReadOnly.

Data Privacy

SequeLink provides data scrambling to ensure the privacy of data. In addition, you can use data encryption to provide a more secure transmission of data across the network. For example, you may want to use data encryption in the following scenarios:

You have offices that share confidential information over an intranet.
You send sensitive data, such as credit card numbers, over a database connection.
You need to comply with government or industry privacy and security requirements.

NOTE: Data encryption may adversely affect performance because of the additional overhead (mainly CPU usage) required to encrypt and decrypt data.

Data Scrambling

Data scrambling ensures that no cleartext messages are transmitted between the client and server over the network. SequeLink provides the following implementations of data scrambling:

Fixed-key DES operates using a 56-bit key.
Fixed-key 3DES operates using a 168-bit key.
Byte swapping means that bytes of data are randomly swapped to scramble data. Different encoded mappings are used for different sessions.

Data scrambling does not provide the same level of security as data encryption and is not enabled by default.

NOTE: Even if you choose not to use a data scrambling method, user IDs and passwords are never sent as cleartext.

See "Configuring Data Privacy" for more information about configuring data scrambling.

Data Encryption

Secure Sockets Layer (SSL) is an industry-standard protocol for sending encrypted data over database connections. SSL secures the integrity of your data by encrypting information and providing client/server authentication.

SequeLink supports SSL for the following types of data transfers:

Between a SequeLink Client and a SequeLink Server on Linux/UNIX/Windows. SequeLink uses SSL for data encryption. For an SSL connection to be successful, both the SequeLink Server and SequeLink Client must be configured for SSL encryption. If a SequeLink Client that is not configured for SSL attempts to connect to a SequeLink Server configured for SSL, the SequeLink Server rejects the connection request and returns the following error message: TCP/IP, connection reset by peer.
Between a SequeLink Client for JDBC and the SequeLink Proxy Server. SequeLink uses SSL for data encryption and authentication.

See "Configuring Data Privacy" for details on configuring SSL for data transfers between a SequeLink Client and SequeLink Server. See "Configuring the SequeLink® Proxy Server" for details on configuring SSL for data transfers between the SequeLink Client for JDBC and the SequeLink Proxy Server.